Booting an operating system of a system using a read ahead technique

ABSTRACT

In one embodiment, the present invention includes a method for generating a list of files accessed during an operating system (OS) boot process to profile the OS boot process, and optimizing the list of files to generate an optimized file list for use in future OS boot processes, where the optimizing is according to a first optimization technique if the files were accessed from a solid state medium and according to a second optimization technique if the files were accessed from a rotating medium. Other embodiments are described and claimed.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a Continuation of U.S. patent application Ser. No.13/114,568 filed May 24, 2011, which is a Continuation of U.S. patentapplication Ser. No. 12/426,582, filed on Apr. 20, 2009, now U.S. Pat.No. 8,230,208, both of which are incorporated herein by reference intheir entirety.

BACKGROUND

Computer systems are formed from a collection of hardware, firmware andsoftware. Typically, a computer system includes one or more processors,memory, peripheral and input/output (IO) devices and so forth. Varioususer applications execute on the computer system under control and usingsystem services of an operating system (OS). Example operating systemsinclude Linux™ and Windows™ operating systems.

Before a user can begin using a computer system, a boot process isperformed upon the power up of the system such that the OS kernel, whichis the main functionality of the operating system, can be initiated. Intypical systems before an operating system boot, normally a basicinput/output system (BIOS) firmware is executed to perform variousself-test and other functions, which then passes off control to an OSboot loader, which is a part of the operating system that is used toload various kernel items needed to enable various system functionality,including providing graphics capability to thus initiate a display toenable the user to log in.

System startup speed is one of the factors users consider whendescribing how fast a computer system is. With the ever increasing bloatof OS software, the boot time for the OS is impacted, causing delaysthat are undesirable to a user.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system in accordance with anembodiment of the present invention.

FIG. 2 is a flow diagram of an overall method of performing a systemstartup in accordance with an embodiment of the present invention.

FIG. 3 is a flow diagram of an optimization process in accordance withone embodiment of the present invention.

FIG. 4 is a flow diagram of an optimized startup process in accordancewith one embodiment of the present invention.

FIG. 5 is a block diagram of a system in accordance with an embodimentof the present invention.

DETAILED DESCRIPTION

In various embodiments, a system startup manager, which may be part ofan OS kernel, may include various sub-functions to enable an efficientOS launch. In one such embodiment, the system startup manager mayinclude a read ahead profile collector, a profile optimizer, a data readahead agent, and a process launcher. However, understand that differentfunctionalities may be provided in various embodiments. Furthermore,understand that in different implementations, each of thesesub-functions may be performed by one or more different components.Furthermore, each execution of a system startup manager need not performall functions. Thus the profile and optimization functions may beexecuted sparingly. For example, such functions may be executed upon aninitial power up of a system to generate and optimize a list of files tobe executed during the OS boot. Then these functions need not beperformed on each powering of a system. Instead, in various embodimentsthese functions may only be further performed upon an update to thesystem. Different levels of updates may trigger these functions to beperformed. For example, some implementations may trigger these functionsonly on a major update such as an OS service pack update. However, otherimplementations may more routinely perform these functions on more minorupdates such as a security update.

As described above, in various embodiments a system startup manager canbe part of an OS kernel. Of course, the scope of the present inventionis not limited in this regard, and other implementations may beperformed in user-level space. For better understanding the context inwhich the system startup manager operates, reference is made to FIG. 1,which is a block diagram of a computer system in accordance with anembodiment of the present invention.

As shown in FIG. 1, computer system 10 is abstracted to include variouslayers including hardware 20, OS kernel 30, and applications 40, whichmay be various user-level software applications that execute on hardware20 using various functions of OS kernel 30. As seen in FIG. 1, hardware20 may include a processor 22, which may be one or more multicoreprocessors, for example. Processor 22 may be coupled to a memory 24,which may be a volatile memory such as a dynamic random access memory(DRAM) and which may function as an OS disk cache, as will be discussedfurther below. In addition, one or more input/output (IO)/peripheraldevices 26 may be present including, for example, a display, a networkinterface, mass storage such as a rotating disk (e.g., a hard drive) ora solid state disk (SSD). While shown with these limited hardwarecomponents, understand that many other such components may be present ina representative system.

Various operations may be performed using hardware 20 under control ofOS kernel 30. In general, OS kernel 30 may perform various functionsrequested by the system or applications 40. To enable a startup inaccordance with an embodiment of the present invention, a system startupmanager 32 may be present. In addition, various other managers andcontrol modules may be present in OS kernel 30. Representative examplesinclude an inter-process communication manager 34, a process controlmanager 36, which may be used to create, destroy and operate on variousprocesses. In addition, an interrupt handler 38 may be used to respondto various interrupts received from hardware or software. Of course, OSkernel 30 may include many more such components. Applications 40 mayinclude various user-level applications that execute using OS kernel 30.While shown with this particular example, in FIG. 1, the scope of thepresent invention is not limited in this regard.

As discussed above, in one embodiment system startup manager 32 mayinclude a profile collector, a profile optimizer, a read ahead agent,and a process launcher. In general, the task of the system startupmanager is to bring the system from a status of “the operating systemkernel has started” to a status of “ready for full user interaction.” Asexamples, this OS kernel launch may include plumbing tasks like checkingand mounting file systems and starting various processes that performbackground and critical tasks. Example tasks on a Linux OS may includelaunching an X server, various daemons, or so forth.

Referring now to FIG. 2, shown is a flow diagram of an overall method ofperforming a system startup in accordance with an embodiment of thepresent invention. More specifically, method 100 may be used to performan initial profiling run and optimization, as well as additionalstartups after such optimization. As seen, first it may be determined onsystem startup whether this is the first power up of a system (diamond105). For example, this determination may take the form of checking anindicator (e.g., present as a flag on the file system, or by the absenceof a previously prepared read ahead list) that indicates whether thesystem has been previously powered up. If so, control passes to block110 where a system startup may be performed. Such startup may be aconventional startup in which files are obtained from memory using diskaccesses and provided to a process launcher to execute the files tolaunch various processes. During such system startup, a list of filesmay be generated (block 120). More specifically this system startup maybe a profiling collection in which this list is generated. In oneembodiment, the list may include both file identifiers and a timeindicator associated with each file. As examples, the time indicator maybe a measurement in time (e.g., in milliseconds (ms)) from beginning ofthe system startup, or it may be a sequence number providing the orderin which files are launched using the process launcher. In either event,the list thus provides file identifiers as well as an indication of thesequential order in which the files were executed.

Then, a profile optimization may be performed to generate an optimizedfile list (block 130). As will be discussed further below, suchoptimization may aim to reduce seek times needed for obtaining the filesfrom their location in storage. This optimized file list may then bestored in a storage medium (block 140). For example, the optimized filelist may be stored in the same storage medium that includes the OSfiles, e.g., a mass storage device such as a disk drive or solid statedisk. At this point, the optimization is completed and normal OSoperations may occur.

Thereafter upon other power ups of the system it may be determinedwhether the system has been updated (diamond 150). Different types ofupdates may cause this determination to be met in this regard. Forexample as discussed above only a major system update such as a newservice pack may trigger this determination, while in otherimplementations a less significant update may trigger the determination.If an update is determined to have occurred, control passes back toblock 110, discussed above. Otherwise, control passes to block 160 wherea read ahead agent may perform a read ahead of startup files using theoptimized file list. When a given amount of such files have beensuccessfully read ahead into OS disk cache space, control passes toblock 170 where a communication may be made to a process launcher thatsuch startup files are present. This enables the process launcher toexecute the startup files directly from the OS cache, without needing torequest the files from mass storage (block 180). Note that theoperations of blocks 160, 170 and 180 may be performed iteratively andin parallel until the OS kernel has been fully booted. While shown withthis particular implementation in the embodiment of FIG. 2, the scope ofthe present invention is not limited in this regard.

Further details of the various operations performed by the components ofa system startup manager are now described. In a profile collection runwhich occurs on initial system startup (as well as after certainupdates), a profile is collected by the read ahead profile collectorcomponent that records which files are used and at what time during theboot process.

During the profile optimization phase, which is performed by the profileoptimizer, the recorded profile is transformed into an optimal datasetfor future use. Specifically, the profile optimizer detects if thesystem is running a solid state disk (SSD) (no seek times) or if thesystem has rotating storage (significant seek times). For the “no seektimes” case, the profile optimization phase includes sorting the list offiles from the profile by first use, as well as detecting which portionsof the files have been actually used. For the SSD case, an optimizedfile list may be generated that includes an identification of files usedduring the OS boot, as well as an indication of the portions of thesefiles used. Furthermore, this list may be sorted according to time offirst use, i.e., sequentially.

For the rotating storage scenario, in addition to these operations, moreextensive work is done to deal with the physical constraints of suchrotating storage, namely seek time. In the rotating scenario, the filelist from the profile is first sorted by time of first use. That is, theoriginal list is re-cast into an ordered list based on first use. Thissorted list is then split into buckets that either represent a fixedamount of time during the boot (e.g., 1 second), or that represent afixed amount of data read from the disk. Then the contents of each ofthese buckets can be optimized to reduce the number of seeks by sortingthe files in the bucket by the starting sector number of the file.

Note that during this process, the optimizer may further scan the entirelist to determine whether any files that are accessed during the bootprocess (but may be present in another bucket) are co-located with anyfiles in the current bucket being optimized. If so, such files may beadded to the current bucket, to reduce the number of disk accesses.While the scope of the present invention is not limited in this regard,whether two files are considered to be co-located may vary based ontheir distance from each other. In some embodiments, such co-locationmay correspond to sharing the same track or being in adjacent sectors.Thus although a given file is to be accessed by the process launcherwith a later bucket's files, due to its co-location it will beeffectively prefetched into the OS disk cache early.

The result of this two-phase sorting is that the file list is sorted bytime on a coarse-grained level, but within these coarse-grained buckets,the file list is sorted to reduce seek times. The resulting optimizedfile list may further include certain metadata regarding the files. Forexample in this optimized file list data structure (which can be storedon the same storage medium on which the OS files are stored) theboundaries between the buckets can be marked. In addition, “files ofinterest” are marked specially as well. These “files of interest” aretypically the application binary files (i.e., executable (.exe) files)of the daemons that are to be started during the boot.

Referring now to FIG. 3, shown is a flow diagram of an optimizationprocess in accordance with one embodiment of the present invention, andwhich may be performed by a profile optimizer of a system startupmanager of an OS kernel, in some embodiments. As shown in FIG. 3, method200 may begin by determining whether the OS files are stored on a solidstate disk or a rotating storage (block 210). If the files are stored ona solid state disk, control passes to block 220 where the optimizationmay be performed by sorting the files by time of first use (block 220).In addition, the resulting optimized file list may include metadata suchas a flagging of the files of interest (block 225).

If instead a rotating storage is present, control passes to block 230.At block 230 the files may also be sorted by time of first use. However,as seen in FIG. 3, additional optimization operations may be performed.Specifically, the files may be divided into buckets (block 240). Thesebuckets as discussed above may correspond to predetermined amounts oftime or data. Then within each of the buckets a sorting may occur basedon disk location (block 250). That is, the files may be reordered withina bucket based on the starting sector number. In other implementations,this re-ordering may be based on alphabetical ordering of the file name.Finally, in generating the optimized list, files of interest may beflagged. In addition, boundaries between the buckets may also be marked(block 260). While shown with this particular implementation in theembodiment of FIG. 3, the scope of the present invention is not limitedin this regard.

After optimization, the list may be used during regular system startups.Early in the startup, the system startup manager activates a data readahead agent subcomponent. This data read ahead agent obtains the listfrom the storage medium and reads the files on this list into theoperating system disk cache (which may be a DRAM) one-by-one. In oneembodiment, this reading can be done in a multithreaded manner whenstored on a SSD storage, and in a single-threaded manner when stored onrotating storage. When the read ahead agent encounters a file ofinterest it records the completion of the reading into the disk cache ina completion list that is stored in memory. Each time the read aheadagent encounters the end of a bucket, the files of interest that wereencountered in the bucket and recorded in the completion list arecommunicated to the process launcher component. In certainimplementations, for the SSD case such communication may not occur.

The process launcher component has a conventional list of applicationsto start that is stored in memory. While the process launcher stilllaunches files in the order set forth in this list, in variousembodiments the process launcher delays launching a process until theread ahead agent has communicated that the file (as well as the rest ofthe bucket that the file was in) has completed its read ahead task. Byintroducing this delay, the startup of a process by the process launcherwill not actually cause a disk IO (since all the data is in the OS cacheby the time the process starts), which avoids the hazard of having sucha disk IO disturb the carefully-sorted-to avoid-seeks IO pattern thatthe read ahead agent is performing. This delay can actually increase theboot performance due to the reality that disks are 10×-50× or morefaster in an optimal IO pattern as compared to a disturbed IO pattern.

Referring now to FIG. 4, shown is a flow diagram of an optimized startupprocess in accordance with one embodiment of the present invention. Asshown in FIG. 4, method 300 may begin by a generally parallel executionof both a read ahead agent, as shown in the stack represented at 310,and a process launcher, as shown in the stack represented at 370. Notethat in general the read ahead agent may first begin execution to startreading files before the process launcher executes, however the scope ofthe present invention is not limited in this regard.

With reference to the read ahead agent, a single file at a time is readfrom the OS store, which may be in mass memory, and stored in the OSdisk cache (block 320). For each file read and stored in the OS diskcache, it may be determined whether the file is a file of interest or abucket end (block 330). If not, control passes back to block 320. If thefile is a file of interest or represents an end of a bucket, controlpasses to block 340 where a file indicator is stored in the completionlist (if it is a file of interest). If the end of the bucket isdetermined at block 350, control passes to block 360, where thecompletion list may be communicated (via communication 365) to theprocess launcher.

As seen in FIG. 4, the process launcher stack begins by identifying anext program to start (block 375). As discussed above, this may be withreference to a list of files present in or accessed by the processlauncher. However, before executing this next program, the processlauncher may enter a wait state (block 380) until it has received acommunication from the read ahead agent that this program is present inthe OS disk cache space. Accordingly, upon receipt of this communication(assuming the file was not already present) the program may be executed(block 390). While shown with this particular implementation in theembodiment of FIG. 4, other embodiments to provide interaction andcommunication between read ahead agent and process launcher arepossible. Embodiments thus provide a smart sorting order, and tie (i.e.,prevent) the start of processes/daemons to progress in the read ahead.

Embodiments may be implemented in many different system types. Referringnow to FIG. 5, shown is a block diagram of a system in accordance withan embodiment of the present invention. As shown in FIG. 5,multiprocessor system 500 is a point-to-point interconnect system, andincludes a first processor 570 and a second processor 580 coupled via apoint-to-point interconnect 550. As shown in FIG. 5, each of processors570 and 580 may be multicore processors, including first and secondprocessor cores (i.e., processor cores 574 a and 574 b and processorcores 584 a and 584 b), although potentially many more cores may bepresent in the processors. The processor cores may boot up one or moreOSs on startup that are stored in a mass storage device in accordancewith an embodiment of the present invention. Still further, theprocessors may execute a portion of the OS kernel to perform anoptimization of a startup file list in accordance with an embodiment ofthe present invention.

Still referring to FIG. 5, first processor 570 further includes a memorycontroller hub (MCH) 572 and point-to-point (P-P) interfaces 576 and578. Similarly, second processor 580 includes a MCH 582 and P-Pinterfaces 586 and 588. As shown in FIG. 5, MCH's 572 and 582 couple theprocessors to respective memories, namely a memory 532 and a memory 534,which may be portions of main memory (e.g., a dynamic random accessmemory (DRAM)) locally attached to the respective processors, and whichmay act as an OS disk cache to store files to be accessed during theboot process. First processor 570 and second processor 580 may becoupled to a chipset 590 via P-P interconnects 552 and 554,respectively. As shown in FIG. 5, chipset 590 includes P-P interfaces594 and 598.

Furthermore, chipset 590 includes an interface 592 to couple chipset 590with a high performance graphics engine 538, by a P-P interconnect 539.In turn, chipset 590 may be coupled to a first bus 516 via an interface596. As shown in FIG. 5, various input/output (I/O) devices 514 may becoupled to first bus 516, along with a bus bridge 518 which couplesfirst bus 516 to a second bus 520. Various devices may be coupled tosecond bus 520 including, for example, a keyboard/mouse 522,communication devices 526 and a data storage unit 528 such as a diskdrive which may include code 530, including in one embodiment an OS. Ofcourse other embodiments may be implemented in a system including a SSDeither in place or in addition to the disk drive in which the OS may bestored. Further, an audio I/O 524 may be coupled to second bus 520.

Embodiments may be implemented in code and may be stored on a storagemedium having stored thereon instructions which can be used to program asystem to perform the instructions. The storage medium may include, butis not limited to, any type of disk including floppy disks, opticaldisks, compact disk read-only memories (CD-ROMs), compact diskrewritables (CD-RWs), and magneto-optical disks, semiconductor devicessuch as read-only memories (ROMs), random access memories (RAMs) such asdynamic random access memories (DRAMs), static random access memories(SRAMs), erasable programmable read-only memories (EPROMs), flashmemories, electrically erasable programmable read-only memories(EEPROMs), magnetic or optical cards, or any other type of mediasuitable for storing electronic instructions.

While the present invention has been described with respect to a limitednumber of embodiments, those skilled in the art will appreciate numerousmodifications and variations therefrom. It is intended that the appendedclaims cover all such modifications and variations as fall within thetrue spirit and scope of this present invention.

What is claimed is: 1-22. (canceled)
 23. A prefetch controller that, inoperation, executes machine-readable instructions that cause theprefetch controller to: generate a list that includes data indicative ofone or more boot files used in a boot sequence of a processor; identifyat least one sector logically associated with each respective one of theone or more boot files; order the identified sectors logicallyassociated with each respective one of the one or more boot files; andtransfer the at least one identified sector logically associated with arespective boot file from a rotating storage device communicably coupledto the processor to a cache memory communicably coupled to the processorprior to execution of the respective boot file.
 24. The prefetchcontroller of claim 23 wherein the machine readable instructions thatcause the prefetch controller to generate a list that includes dataindicative of one or more boot files used in a boot sequence of aprocessor further cause the prefetch controller to: generate at leastone file that includes data representative of at least a file identifierlogically associated with each of the boot files.
 25. The prefetchcontroller of claim 23 wherein the machine readable instructions thatcause the prefetch controller to generate a list that includes dataindicative of one or more boot files used in a boot sequence of aprocessor, further cause the prefetch controller to: update at least onefile that includes data representative of at least a file identifierlogically associated with each of the boot files.
 26. The prefetchcontroller of claim 23 wherein the machine readable instructions thatcause the prefetch controller to order the identified sectors logicallyassociated with each respective one of the one or more boot filesfurther cause the prefetch controller to: order the identified sectorslogically associated with each respective one of the one or more bootfiles by a starting sector number logically associated with eachrespective one of the one or more boot files.
 27. The prefetchcontroller of claim 23 wherein the machine readable instructions thatcause the prefetch controller to transfer the at least one identifiedsector logically associated with a respective boot file from a rotatingstorage device communicably coupled to the processor to a cache memorycommunicably coupled to the processor prior to execution of therespective boot file, further cause the prefetch controller to: transferthe at least one identified sector logically associated with therespective boot file from the rotating storage device to the cachememory prior to execution of the respective boot file, the at least oneidentified sector selected based at least in part on the list of bootfiles.
 28. The prefetch controller of claim 23 wherein the machinereadable instructions that cause the prefetch controller to transfer theat least one identified sector logically associated with a respectiveboot file from a rotating storage device to a cache memory prior toexecution of the respective boot file, further cause the prefetchcontroller to: transfer the at least one identified sector logicallyassociated with a first boot file; execute at least a portion of thefirst boot file by the processor; and contemporaneous with executing thefirst boot file, transfer the at least one identified sector logicallyassociated with a second boot file from the rotating storage device tothe cache memory.
 29. The prefetch controller of claim 23 wherein themachine readable instructions that cause the prefetch controller togenerate a list that includes data indicative of one or more boot filesused in a boot sequence of a processor, further cause the prefetchcontroller to: generate a list that includes data indicative of an orderof execution of the boot files.
 30. The prefetch controller of claim 23wherein the machine readable instructions that cause the prefetchcontroller to order the identified sectors logically associated witheach respective one of the one or more boot files, further cause theprefetch controller to: order the identified sectors logicallyassociated with each respective one of the one or more boot files basedat least in part on the order of execution of the boot files.
 31. Theprefetch controller of claim 23 wherein the machine readableinstructions that cause the prefetch controller to transfer the at leastone identified sector logically associated with a respective boot filefrom a rotating storage device to a cache memory prior to execution ofthe respective boot file, further cause the prefetch controller to:transfer the at least one identified sector logically associated withthe respective boot file from the rotating storage device to anoperating system cache memory prior to execution of the respective bootfile.
 32. A storage device that includes machine-readable instructions,that when executed by at least one processor, cause the at least oneprocessor to: responsive to detecting a communicably coupled rotatingstorage device: generate a list that includes data indicative of one ormore boot files used in a boot sequence; identify at least one sectorlogically associated with each respective one of the one or more bootfiles; order the identified sectors logically associated with eachrespective one of the one or more boot files; and transfer the at leastone identified sector logically associated with a respective boot filefrom a rotating storage device to a cache memory prior to execution ofthe respective boot file.
 33. The storage device of claim 32 wherein themachine-readable instructions that cause the at least one processor toorder the identified sectors logically associated with each respectiveone of the one or more boot files, further cause the at least oneprocessor to: order the identified sectors logically associated witheach respective one of the one or more boot files by a starting sectornumber of each of the identified sectors.
 34. The storage device ofclaim 32 wherein the machine-readable instructions that cause the atleast one processor to transfer the at least one identified sectorlogically associated with a respective boot file from a rotating storagedevice to a cache memory prior to execution of the respective boot file,further cause the at least one processor to: transfer the at least oneidentified sector logically associated with the respective boot filefrom the rotating storage device to an operating system cache memoryprior to execution of the respective boot file.
 35. The storage deviceof claim 32 wherein the machine-readable instructions that cause the atleast one processor to transfer the at least one identified sectorlogically associated with a respective boot file from a rotating storagedevice to a cache memory prior to execution of the respective boot file,further cause the at least one processor to: transfer the at least oneidentified sector logically associated with a first boot file; andtransfer at least one identified sector logically associated with asecond boot file contemporaneous with execution of the at least oneidentified sector logically associated with the first boot file.
 36. Thestorage device of claim 32 wherein the machine-readable instructionsthat cause the at least one processor to generate a list that includesdata indicative of one or more boot files used in a boot sequence,further cause the at least one processor to: generate a list thatincludes data indicative of an execution order for at least some of theone or more boot files.
 37. The storage device of claim 32 wherein themachine-readable instructions that cause the at least one processor toorder the identified sectors logically associated with each respectiveone of the one or more boot files, further cause the at least oneprocessor to: order the identified sectors logically associated witheach respective one of the one or more boot files based at least in parton an execution sequence of the one or more boot files.
 38. The storagedevice of claim 32 wherein the machine-readable instructions that causethe at least one processor to transfer the at least one identifiedsector logically associated with a respective boot file from a rotatingstorage device to a cache memory prior to execution of the respectiveboot file, further cause the at least one processor to: transfer the atleast one identified sector logically associated with the respectiveboot file from the rotating storage device to an operating system cachememory prior to execution of the respective boot file.
 39. A method ofprefetching boot files, comprising: responsive to detecting acommunicably coupled rotating storage device: generating, by aprocessor, a list that includes data indicative of one or more bootfiles used in a boot sequence; identifying, by the processor, at leastone sector logically associated with each respective one of the one ormore boot files; ordering, by the processor, the identified sectorslogically associated with each respective one of the one or more bootfiles; and transferring the at least one identified sector logicallyassociated with a respective boot file from a rotating storage devicecommunicably coupled to the processor to a cache memory communicablycoupled to the processor prior to execution of the respective boot fileby the processor.
 40. The method of claim 39 wherein generating a listthat includes data indicative of one or more boot files used in a bootsequence comprises: generating, by the processor, at least one file thatincludes data representative of at least a file identifier logicallyassociated with the one or more boot files.
 41. The method of claim 39wherein generating a list that includes data indicative of one or moreboot files used in a boot sequence comprises: updating, by theprocessor, at least one boot log file that includes data representativeof at least a file identifier logically associated with the one or moreboot files.
 42. The method of claim 39 wherein ordering the identifiedsectors logically associated with each respective one of the one or moreboot files comprises: ordering the identified sectors logicallyassociated with each respective one of the one or more boot files by astarting sector number associated with each of the respective bootfiles.
 43. The method of claim 39 wherein transferring the at least oneidentified sector logically associated with a respective boot file froma rotating storage device communicably coupled to the processor to acache memory communicably coupled to the processor prior to execution ofthe respective boot file by the processor comprises: transferring the atleast one identified sector logically associated with the respectiveboot file from the rotating storage device to a cache memory prior toexecution of the respective boot file by the processor, the at least oneidentified sector selected, based at least in part, on the list of bootfiles.
 44. The method of claim 39 wherein transferring the at least oneidentified sector logically associated with a respective boot file froma rotating storage device communicably coupled to the processor to acache memory communicably coupled to the processor prior to execution ofthe respective boot file by the processor comprises: transferring the atleast one identified sector logically associated with a first boot file;executing at least a portion of the first boot file by the processor;and contemporaneous with executing the first boot file, transferring theat least one identified sector logically associated with a second bootfile from the rotating storage device to the cache memory.
 45. Themethod of claim 39 wherein generating a list that includes dataindicative of one or more boot files used in a boot sequence comprises:generating a list that includes data representative of an order ofexecution for at least a portion of the boot files in the list.
 46. Themethod of claim 45 wherein ordering the identified sectors logicallyassociated with each respective one of the one or more boot filescomprises: ordering the identified sectors logically associated witheach respective one of the one or more boot files based at least in parton the order of execution for at least a portion of the boot files inthe list.
 47. The method of claim 39 wherein transferring the at leastone identified sector logically associated with a respective boot filefrom a rotating storage device to a cache memory prior to execution ofthe respective boot file by the processor comprises: transferring the atleast one identified sector logically associated with the respectiveboot file from a rotating storage device to an operating system cachememory communicably coupled to the processor prior to execution of therespective boot file by the processor.